Enterprise software systems are generally large and complex. Such systems can require many different components, distributed across many different hardware platforms, possibly in several different geographical locations. In order to design, configure, update or implement an enterprise software system, one is generally required to understand details of the system at varying levels, depending on his role in designing, managing or implementing the system. For example, a systems administrator may need a high-level technical understanding of how various software modules are installed on physical hardware, such as a server device or a network, and how those software modules interact with other software modules in the system. A person responsible for configuring the software may utilize a high-level functional understanding of the operations that each functional component provides. An application designer may utilize a low-level technical understanding of the various software interfaces that portions of the application require or implement. And an application developer may utilize a detailed understanding of the interfaces and functionality he is implementing in relation to the remainder of the system. But the flow of a business process within an application today is typically hidden from a user. In some cases, it is possible to manually create a textual or graphical documentation of this process flow. However, this documentation is typically not detailed enough and can become quickly outdated since its consistency with the actual application software is not (initially) verified or maintained automatically.
Within a development environment, an application can be developed using modeling systems. In general, these models can specify the types of development objects or components that can be used to build applications, as well as the relationships that can be used to connect those components. In an object-oriented architecture, for example, a defined application can include a combination of various data objects and resources (i.e., development objects). In that example, relationships among the development objects can include a relationship indicating that one data object inherits characteristics from another data object. Another example architecture is the model-view-controller (MVC) architecture. Applications built using the MVC architecture typically include three different types of components—models, which store data such as application data; views, which display information from one or more models; and controllers, which can relate views to models, for example, by receiving events (e.g., events raised by user interaction with one or more views) and invoking corresponding changes in one or more models. When changes occur in a model, the model can update its views. Data binding can be used for data transport between a view and its associated model or controller. For example, a table view (or a table including cells that are organized in rows and columns) can be bound to a corresponding table in a model or controller. Such a binding indicates that the table is to serve as the data source for the table view and, consequently, that the table view is to display data from the table. Continuing with this example, the table view can be replaced by another view, such as a graph view. If the graph view is bound to the same table, the graph view can display the data from the table without requiring any changes to the model or controller. In the MVC architecture, development objects can include models, views, controllers, and components that make up the models, views, and controllers. For example, application data in a model can be an example of a component that is a development object.
To graphically model an application such that a combination of abstract, graphical representations represent the components of the application and the relationships between those components, a developer typically uses a drawing tool, such as Microsoft Visio, that provides abstract representations and tools for manipulating and/or generating abstract representations. For example, a user of the drawing tool (such as a developer) can choose to use a circle (or any other suitable abstract representation or model) to represent a class (such as a class defined in the C++ or other object-oriented programming language) of an application developed under the object-oriented architecture. The circle that represents a development object can include data from the development object. For example, a name of a class (i.e., data from a development object) can be entered in a text box that is part of the circle, and that name can be displayed in the center of the circle. In addition to drawing tools, the developer can also use other graphical tools to generate graphical representations and models (e.g., Unified Modeling Language (UML) diagrams or Business Process Execution Languages (BPEL)) from application code or vice versa.